The invention relates generally to information security, and in particular, to a method, system, and storage medium for eliminating password exposure when requesting third-party attribute certificates.
Attribute Certificates (ACs) and Public Key Certificates (PKCs) are used to protect access to electronic information and may be implemented in a variety of applications requiring distributed security such as Internet mail, IPSec, and web applications. While these certificates are structurally similar, one significant difference between the two is that an AC does not contain a public key—instead it normally contains the identity or subject name of a PKC. An AC seeks to certify (i.e., securely bind) a set of authorization capabilities to the AC holder (e.g., group membership, role, security clearance, etc), while a PKC binds a public key to the PKC holder. This authorization information may be placed in either of a PKC extension or the AC; however, it is not generally recommended to place the authorization information into the PKC because the authorization information typically has a shorter lifespan than that of the public key, which may last for years. Thus, when the authorization information changes, the PKC is no longer valid. Further, if the PKC issuer and authorization enterprise are different entities, the PKC issuer would be required to obtain approval from the authorization enterprise before including the authorization information in the PKC, which is inefficient.
When making an access control decision based upon an AC, a verification procedure may be required to ensure that the appropriate AC holder is the entity that has requested access. This verification may be accomplished by establishing a link to a PKC that corresponds to the AC and using a private key associated with the PKC for performing authentication. FIG. 1 illustrates a block diagram of an X.509 AC 102 that is linked to a corresponding X.509 PKC 106 via a holder 104 of the AC 102. X.509 is a standard used to define digital certificates and attribute certificates as recommended by the International Telecommunication Union (ITU), an intergovernmental organization that develops telecommunications technologies. A trust path 110 is established in the AC 102 by tracing back the holder 104 of the AC 102 to the associated PKC 106 during a validation procedure. One attribute of the AC 102 is the Service Authentication Information attribute 108, which is defined by the following ASN.1 syntax:
SvceAuthInfo ::=  SEQUENCE {   service    GeneralName,   ident    GeneralName,   authInfo    OCTET STRING OPTIONAL}
The Service Authentication Information attribute 108 is used for packaging a target system name (service) with authentication information such as an identity (ident) and a credential (authInfo). For a legacy application, the identity may be a username and the credential may be password. A target service/system may authenticate the AC holder once it receives the certificate 102 as a result of some type of security protocol between the user and the target service. Such a security protocol would establish the user as the owner of the PKC (e.g., SSL or its successor, TLS). In order to protect the sensitive data upon creation of the AC, the user's credentials information (i.e., SvceAuthInfo) may be encrypted using the public key of the target service. In accordance with the recommendations outlined in RFC3281, the credential information is encrypted by the AC issuer and placed in another attribute called encAttrs prior to inclusion in the AC. In addition to the credential information, the encrypted data would also include the AC issuer's name and AC serial number. This extra information uniquely binds the credential information to the AC containing it. Thus, when evaluating the AC, the target system can verify that the credential information is genuine, and that it has not been stolen from another AC as part of a replay attack.
The following two drawbacks are attributable to the above solution: (1) a potential for password exposure where the AC issuer is a third party; and (2) a change in the password would render the AC unusable. Regarding the first drawback, the above solution would compel the AC issuer and target service/system to be one and the same. If the AC issuer were a third party not having access to the target service/system's credentials database, the AC requester would be required to present the clear text password to the AC issuer when requesting the AC, thus unduly exposing the password to what may not be a trustworthy third party. The credential information cannot be pre-encrypted by the requester prior to requesting the AC, as neither the requester nor the target system would normally know the serial number of a certificate yet to be issued, while the AC issuer should not need to know the password. With respect to the second drawback, since the requester's password is contained in the AC (encrypted), any password change for the requester on the target would render the AC unusable. In fact, any use of the AC after the password change may appear as a break-in attempt.